home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Oct 90 / MacApp.Tech$ 10⁄5⁄90 / 2112-Re Inside Out⁄MacApp-Oct90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  7.2 KB  |  171 lines  |  [TEXT/GEOL]
  1. Item    2183173                         3-Oct-90        14:05PDT
  2.  
  3. From:   D2086                           Efficient Field Svc, C Faith,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    RE: Inside Out/MacApp (Long)
  8.  
  9. Andrew,
  10.  
  11. I hope that it is indeed andrew who sent this message, but there was no name in
  12. the closing.
  13.  
  14. I have worked extensively with Inside Out and MacApp.  I have looked at the
  15. problem of integration from many perspectives.
  16.  
  17. There are no pat answers to the questions you ask.  Too much depends on the
  18. data you are using and what uses you intend to put it to.
  19.  
  20. Where TDocument fits in is also a very complex issue.
  21.  
  22. My personal opinion is that TDatabase should indeed descend from TDocument, but
  23. first some background:
  24.  
  25. Bruce "Tog" Tognazzini in his article "Principles to Design by", September
  26. AppleDirect, talks about Don Normans concepts of there being 3 conceptual
  27. models at work in an application.  The Design Model, the designers concept of
  28. the application at work, the System Image which is the integration of the
  29. design model into the application itself, and last but definately not lead the
  30. User Model which is the users concept of how things work.
  31.  
  32. Enter TDocument,  just what is this thing?  Does it represent an entity in the
  33. Design Model, the User Model or both.  It really represents an entity in the
  34. Design Model that lets MacApp users create a User Model that is consistent with
  35. other Macintosh Applications.
  36.  
  37. Here are some of the UserModel - Design Model action pairs that TDocument
  38. handles.
  39.  
  40. USER ACTION                         DESIGN ACTION
  41. Choose Print menu item              TDocument DoMenuCommand with cPrint cmd
  42.  
  43. User expects the frontmost window's data to be printed in an appropriate form.
  44. Usually this means a WYSIWYG representation of the data that appears on the
  45. screen, though sometimes this is not appropriate.
  46.  
  47. Double Click Document from finder   Calls TApplication handle finder request
  48.                                     which calls OpenOld which makes a TDocument
  49.                                     via DoMakeDocument that corresponds to the
  50.                                     finder document.
  51.  
  52. User expects the application that handles that type of icon to open so that he
  53. can do some work with it.  The document he clicked on should be opened
  54. automatically by the application.  This should be the same as starting the
  55. application and then opening the document from the file menu.
  56.  
  57. Close the only open window          Calls TDocument close for the TDocument
  58.                                     which owns the window.
  59.  
  60. User expects that the disk representation of this document will now be closed
  61. so that he does not have to close this himself.
  62.  
  63. Choose Save menu item               Calls TDocument DoMenuCommand with command
  64.                                     cSave, resulting in the posting of a
  65.                                     TSaveDocCommand which in turn calls
  66.                                     TDocument.Save
  67.  
  68. The user expects that the data associated with the topmost window will be saved
  69. to his disk so that he will be able to find it later.
  70.  
  71. Choose Revert menu item             Calls TDocument DomenuCommand eventually
  72.                                     resulting in a call to TDocument.Revert.
  73.  
  74. The user expects to see the data that was there before he made some foolish
  75. changes he wishes he did not make.
  76.  
  77. Notice that there are really two types of mappings here that relate to
  78. TDocument, actions that relate to a disk ICON and actions that relate to the
  79. data in the topmost window.  These are two entirely different concepts.
  80.  
  81. They are often associated in a one to one relation in such applications as
  82. WriteNow, Canvas, MacPaint, even AppleLink itself.  This is why TDocument
  83. handles both of these cases.
  84.  
  85. So where does Inside Out fit in.
  86.  
  87. The best place to begin is to decide which if any of the two groups of actions
  88. that relate to TDocument and user actions might be related to Inside Out.
  89.  
  90. One thing that can be said for certain is that there will always be a one to
  91. one relationship between an Inside Out database and a macintosh ICON.  The real
  92. unknown is what the application will do with that data.
  93.  
  94. To really understand this we must discuss another subject, that which Jeff
  95. Alger in his May 1990 Framework's article "Using Model-View_Controller with
  96. MacApp" describes as Documentness.  Documentness relates to the data in the
  97. topmost window, that is that data which the user can expect to be saved when he
  98. chooses the save command.  I prefer to think of these as Saveable Entities and
  99. not documents.
  100.  
  101. If an application uses an Inside Out database to represent only one Saveable
  102. Entity then it is easy to see that a TDocument representing the entire database
  103. would be a natural.
  104.  
  105. The problem comes when an Inside Out database represents many (possibly
  106. thousands of saveable entities), where does TDocument fit in now.
  107.  
  108. I still submit that a TDocument representing the whole database is desirable.
  109. This will allow the existing MacApp framework to be used reasonably well.
  110. Things like double clicking on a database file ICON will do the right thing.
  111.  
  112. I don't think that this should necesarily be the only TDocument.  There should
  113. also probably be a TDocument for each Saveable Entity represented by a window.
  114. What these sub-TDocuments represent depends on the application and may change
  115. depending on the context.
  116.  
  117. For example there might be a window that contains a list of customer
  118. information any of which can be editted at the same time with no further action
  119. on the part of the user.  In this case the TDocument really represents the
  120. entire list of customers.  In another case there might be only one customer in
  121. the window, the TDocument would at this time represent this one customer.
  122.  
  123. If we think in terms of what the User would expect to happen as a result of a
  124. save operation this becomes a little easier to think about.
  125.  
  126. In the case of a list of customers when 5 have been changed a save operation
  127. would expect to save all 5 customers.
  128.  
  129. Jeff makes the very good point that "There can be no mixing and matching of
  130. documents within a window"
  131.  
  132. What this means in terms of Don Norman's conceptual models is that all efforts
  133. should be made to ensure that the Design Model completely supports a consistent
  134. User Model.
  135.  
  136. What actually will be save should never be ambiguous.  It never will be if
  137. there is one and only one TDocument per window.  There can be many windows per
  138. document just not the other way around.
  139.  
  140. Unfortunately MacApp's TDocument is much harder to coerce into this abstract
  141. Saveable Entity concept than it should be.  MacApp not only assumes that each
  142. TDocument represents a disk file it also assumes the format of that disk file
  143. and how it should be read into a TDocument.  Not very nice for an abstract
  144. class.
  145.  
  146. In summary, there should be one TDocument representing the entire Inside Out
  147. database and another for each Saveable Entity represented in the application.
  148. There should never be more than one TDocument per window.
  149.  
  150. I hope this mud has not weighed the discussion down even further,
  151.  
  152. I remain, as ever,
  153. Curtis Faith
  154.  
  155. P.S. I would really like to get a workshop together at the MADA conference to
  156. discuss just these issues in REAL DEPTH.
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.